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Note to Reader 


1. For an overview of the study, it is recommended that the 
reader begin with Part I, "Purpose and Scope", followed by 

Part V, "Summary and Conclusions." 

2. It would be useful for readers to review Part VII, "Notes 
on Terminology" before addressing the remainder of the study 

to familiarize themselves with certain study terminology and 
concepts that may be both unusual and confusing. 

3. Footnotes and Appendixes are either at the end of a 
Part, or in Part IV, at the end of each cost element. Footnotes 
for tables are on the table page itself. 
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Part I: Purpose and Scope 

Compatibility with existing ODP hardware/sof tware 
implies IBM compatibility. This study, however, does not 
address the disadvantages or advantages of IBM architecture, 
hardware or software, either in a technical or cost sense. 
Technical and cost evaluation are more appropriately performed 
during a formal evaluation of vendor proposals submitted in 
response to an RFP . This study addresses the impact of 
compatibility on ODP management and resources; the fact 
that the common architecture is IBM is not significant. 

This ODP internal impact is primarily due to factors such as 
the greater possibility for resource sharing with a common 
ODP architecture. Generally speaking, it is difficult to 
structure an RFP to include these factors. (1) 

It should be emphasized at the outset that this study 
addresses only the compatibility of the CIA SAFE system with 
ODP. A counterpart study on the value of DIA compatibility 
is in progress. Since SAFE ADPE will be common to both CIA 
and DIA, until the two studies are reconciled, no final 
"value of compatibility" can be derived. 

It is hoped that this study will serve to clarify the 
value of compatibility in terms of aggregate cost savings 
and other qualitative factors. This value must only be 
interpreted, however, in terms of an overall assessment that 
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includes procurement issues, technical, management/administrative 
and cost factors. For example, there may be an overriding 
technical reason for preferring one architecture over the 
others or the cost savings associated with a specific architecture 
may overwhelm any cost savings associated with compatibility.. 

The required overall assessment should, in most cases, take 

the form of a formal evaluation of vendor responses to an 
RFP . 


Examples of external factors explicitly excluded from 
this study which are often associated with the common architecture 
concept but in fact are attributes of a specific architecture 
(e.,g. , IBM) are: the potential for multi— sourcing and the 
availability of a very large commercial software base. This 
study makes no effort to evaluate the truth of these assertions 
or their impact. Such an evaluation, if appropriate, should 
be done as part of an overall evaluation, since the factors 
described are not related to compatibility. 

Finally, no effort has been made to evaluate the impact 
of Federal Information Processing Standards 60-63, which 
deal with I/O interface standards and have the practical 
impact of restricting most future procurements to mainframes 
that function with IBM-compatible peripherals. These standards, 
which come into effect during FY-80, may have a profound 
impact on the SAFE 
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ADPE procurement. The existence of these standards is an 
external factor and not associated with compatibility. It 
should be noted, however, that an IBM-compatible architecture 
will in fact meet the standard. It is not known at this time 
whether vendors of other mainframe architectures will have 
offerings that also meet the standards. 

How, in a practical sense, should the results of this 
study and its DIA equivalent be used? First, a unified ODP- 
CSPO-DIA position on the "value of compatibility" must be 
arrived at. This value will have to be assessed as to whether 
it is an overriding factor or just another factor to be 
considered in the formal procurement evaluation. This decision 
as to whether it is an overriding factor is a critical one. 
Such a decision would be made if it were believed that the 
value of compatibility was so significant that the outcome 
of the procurement was, in effect, predetermined (at least 
as far as architecture) . The purpose of restricting the pro- 
curement explicitly would be to avoid "exercising the market- 
place." Of course, any restriction of the procurement would 
have to be made only after the responsible individuals con- 
vinced themselves that the case for the value of compatibility 
was absolutely oompelling and it would be unrealistic to 
believe that a high score in other evaluation criteria could 
overwhelm the compatibility weight. The above is definitely 
not meant as an argument for restriction of the procurement. 
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In fact, in a procurement such as the SAFE ADPE, which is in 

the nature of a new start, a very strong case indeed would be 
required to restrict the procurement. It must be remembered 
that the government routinely is expected to absorb very 
heavy costs in the interests of open competition in the ADPE 
arena (e.g., software conversion costs, in particular assembly 
language code) . 

If a decision is made that the value of compatibility is 
not overriding, or that issues of procurement policy require 
that the procurement not restrict architectures, a method must 
be developed to "fold- in" the value of compatibility to the 
formal proposal evaluation. This will be a part of the overall 
SAFE ADPE procurement stretegy which is currently under 
development. 


(1) Suggestions on how to directly integrate at least some 
ODP internal factors into the RFP are provided in the detailed 
discussion (see Part IV) . 
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Part II . Introduction 

OOP operates two major centers in the Headquarters 
complex: the Ruffing Center and the Special Center. Both 

centers are compatible in terms of hardware and system 
software. It is commonly believed within ODP that this 
compatibility between centers permits significant cost savings 
and provides management and operational benefits. The CIA 
SAFE computer center is scheduled for IOC in 1982. It is 
reasonable to ask what cost savings and benefits could be 
achieved if SAFE were required to be compatible with the 
existing ODP centers. The purpose of this study is to examine 
the issue of cost-savings and benefits associated with SAFE 
compatibility. Our goal would be to quantify the value of 
SAFE compatibility in dollar terms for use in the evaluation 
scheme of the SAFE hardware and system software competitive 
procurement. The final derived "value of compatibility" 
could be, for example, added to the cost of any proposed system 
that was non-compatible in an analogous manner to the handling 
of software conversion costs in proposal evaluation. It is 
believed that this approach is fair to both the marketplace, 
in that it permits an unrestricted procurement, and fair to 
the government, in that real-world government costs and 
benefits are evaluated. 

In the next section, an attempt is made to arrive at a 
definition of compatibility that is suitable for our purposes. 
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The remainder of the study is devoted to a discussion of the 
impact of compatibility and an attempt to measure this impact 
in dollar terms, where possible. 

Definition of Compatibility 

The aspects of compatibility we are concerned with are 
those that enhance the possibility that ODP Ruffing Center 
and Special Center resources (staff and equipment) are shareable 
by SAFE at little or no additional cost. Examples of the 
support ODP resources could provide that would be facilitated 
by compatibility are operating system support, processing 
support and trained staff both on a regular and reserve (i.e., 
backup) basis. Another possibility for benefits is from 
consolidated procurement of compatible hardware and software. 

Four levels of compatibility have been identified that 
would affect the opportunities for resource sharing. These 
are defined below in order of increasing compatibility. It 
should be noted that these four compatibility states represent 
a vastly oversimplified view of a compability situation that 
has a multitude of possibilities. 

1. Non-Compatibility (N/C) 

Non-compatibility is defined as SAFE mainframes 
that are not IBM-compatible (i.e., non-compatible 
mainframes are therefore those that do not utilize 
the IBM 370 series instruction repertoire) . With 
one minor exception, ODP mainframes in the Ruffing and 
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2. Hardware Compatibility (H/C) 

SAFE mainframes are IBM-compatible, do utilize 
the IBM 370 series instruction repertoire as ODP 
mainframes in the Ruffing and Special Centers do. 

3. Hardware/Software Compatibility (H/S/C) 

SAFE mainframes are IBM-compatible and SAFE 
operating system software is an ODP -supported 
IBM operating system (currently, MVS or VM) . 

4 . Full Compatibility (F/C ) 

SAFE mainframes are IBM-compatible; operating 
system software is ODP— supported (i.e., currently 
MVS or VM) and the SAFE primary DBMS is an 
ODP-supported DBMS (.currently GIM II) . 

In both the system software and DBMS areas, 
the requirement for ODP support is significant, 
since the depth of support is a measure of the 
available ODP resources that might be utilized by 
SAFE. For example, if SAFE mainframes are H/S 
compatible with ODP it would be generally possible 
to run the same DBMS on either. Some benefits 
would accrue from this possibility (e.g., in the 
backup area) . However, if ODP does not support 
the particular DBMS, no in-place system programming 
or system engineering expertise would routinely be 
available. Thus to obtain maximum benefits from 
operating system and DBMS compatibility, supported 
systems are required. 
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The above compatibility definitions referred to SAFE 
mainframes as if they all were to have similar hardware and 
software configurations. This will not necessarily be the 
case. The proposed SAFE system architecture involves two 
levels of processors:: the so-called maxi and midi levels. 

Even assuming that all hardware and software is similar and 
likewise all midi H/S is similar, compatibility questions 
become very complicated. It is possible to have maxi com- 
patibility with ODP mainframes and midi non-compatibility; 
maxi and midi compatibility with ODP mainframes (though of 
varying types — e.g ., different 0/S or DBMS); or less likely, 
maxi non-compatibility and midi compatibility. 

In short, even in our simplified model of the compatibility 
situation, there are sixteen possibilities. The most likely 
possibilities are summarized below. (.2) 


Maxi 

Midi 

N/C 

N/C 

H/C 

H/C 

H/S/C 

H/S/C 

H/C 

H/S/C 

H/S/C 

H/C 


Each one of these situations presents different opportunities 
for resource sharing. 
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Footnotes to Part XI 


(1) The TADS computer, an IBM 360/67, is the minor deviation 
from full IBM 370-series compatibility. 

(2) There are sixteen possibilities, since there are four 
compatibility situations each, for both the maxi and midi. 
Five states may be singled out as most likely under the 
following assumptions: 1) the SAFE maxi and midi may be 
required to have a homogeneous architecture to minimize the 
complexity of software development. 2) full compatibility 
for either the midi or maxi is unlikely due to GIM II 's 
apparent non-suitability for SAFE. 
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Part III: Overview of the Study 

The Compatibility Issue 

This study attempts to estimate the impact, in cost terms, 
of a non-compatible CIA SAFE system. Non-compatibility, as used 
herein, refers to a SAFE system that is not hardware (and there- 
fore not software) compatible with the ODP Ruffing and Special 
Centers. This is equivalent to a SAFE system that is not con- 
figured with IBM or IBM plug-compatible mainframes. (It should 
be noted that the SAFE mainframe architecture has not been 
selected at this writing and it is the purpose of this study to 
assist in the selection by clarifying the value of compatibility. 

Part I, "Purpose and Scope" expands upon this point.) 

As discussed in Part II, "Introduction," the compatibility 

issue gets very complicated very quickly as there are numerous 

possibilities caused by two levels of SAFE mainframe hardware 

and the several possibilities in the area of operating system 

software. For the purposes of this impact analysis, costs will 

be derived that quantify the difference in impact to ODP between: 

( Homogeneous SAFE Midi & Maxi H/S 

( 

H/S Compatible SAFE: ( IBM or IBM Plug-Compatible Hardware 

( 

( ODP-supported Operating System 
( (i.e. , VM or MVS) 

and 

Non-Compatible SAFE : ( SAFE Midi & Maxi are not IBM or 

IBM Plug-Compatible 
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In order to simplify the analysis, the assumption has been 
made that SAFE will fall into one of the categories above. 

Mixed modes have therefore been ignored (e.g., heterogeneous 
midi and maxi; non-ODP-supported O/S, etc.). This assumption 
is believed to be realistic. 

The Model 

In thinking about the impact of a non-compatible archi- 
tecture on an organization such as ODP, we have chosen to 
organize our thoughts around a specific "model." From the 
viewpoint of this model, a non-compatible SAFE architecture 
implies a "barrier" within ODP. This architecture barrier 
impedes the transfer of resources between SAFE and other ODP 
centers, as well as the related problem: the transfer of 
workload. (Management can either transfer resources — people, 
hardware, software, etc. — to the "work," or transfer the 
workload to the resources — i.e., load sharing.) Costs must 
be incurred in overcoming the architecture barrier or a reduced 
capability must be accepted. Examples are systems programming 
support and overflow load sharing in a non-compatible environ- 
ment. The former can be overcome by providing separate system 
programming support in the SAFE center (i.e., for the non-IBM 
O/S) . The latter workload transfer problem would cause a non- 
compatible ODP to, for example, live with a batch backlog 
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(i.e., a reduced capability as compared to a compatible 
environment) . 

Table III summarizes the resource/workload categories 
and the detailed areas of non-compatibility impact. Part 
IV assesses the impact in each area with an attempt to develop 
a cost estimate, where feasible. 

The Cost Impact 

Costs are derived over the systems life and not the 

architecture life. The rationale behind this choice is 

discussed in Appendix III. Though the use of evaluated costs 

(often referred to as discounted or present value costs) is 

technically correct for combining costs distributed over time, 

this approach has not been followed. This decision has been 

(1) 

made because of the time involved in developing these costs 
and our belief that the costs developed in this study are 
useful as rough measures of aggregate impact only. If the 
costs are to be used directly in proposal evaluation, dis- 
counted costs will be required. Costs have therefore been 
assumed in constant 1979 dollars. Occasionally, costs were 
most conveniently developed in FY-79 dollars. For all practical 
purposes, FY-79 dollars are assumed equal to 1979 dollars. 


(1) Actually, the time involved in updating these costs, as it 
is assumed that after discussion, revisions to the costs estimates 
will inevitably be required. 
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TABLE III 

Summary Sheet: Cost of Non-Compatibility 

with Existing ODP Hardware/ Software 


Resource/workload 

Category 


Impact 

(Cost Element No) 


A. Management Expertise 


B. People 


A~I : Increased Management Complexity and 
Program Risk 

B-l : Impact on Personnel Management 
B-2: Increased Vendor System Training 
B-3: Additional Personnel Requirements 


C. Hardware/Software 


C-l: Limitations on Reconfiguration & 
Reutilization 


C-2: Unavailability of Emergency and 
Limited Disaster Hardware Backup 

C-3: Consolidated Procurement 

C-4: Software Exchange Limitations 
( Continued) 
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Resource /Workload 
Category 


D. Workload 


TABLE III 

Summary Sheet: Cost of Non-Compatibility 

with Existing ODP Hardware/ Software (con't) 

Impact 

(Cost Element No.) 

D: Technical Barriers to Load Sharing (see following) 

D~l: Routine Production Load Sharing 
D-2: Routine Development Load Sharing 
D-3: Backup Load Sharing (see following) 

D-3(a): Overflow Load Sharing 
D-3(b) : Disaster Backup 
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Appendix III: Systems Life vs. Architecture Life 

An important distinction can be made between systems 
life and architecture life. Systems life, as conventionally 
used, refers to the useful life of hardware in support of a 
specific service. Architecture life goes beyond system life 
and represents, the estimated time until a total system 
reprocurement (i.e., hardware and software) will be performed. 

Typically, at the end of system life, a hardware upgrade 
is performed and the replaced hardware is reutilized; soft- 
ware, however, is. not totally redesigned. The end of archi- 
tecture life, as defined herein, implies that software requires a 
"bottom-up" redesign due to system deficiencies, the increased 
cost of maintenance and/or evolving requirements. A competitive 
reprocurement of the complete system opens up the possibility 
of a change in architecture. 

For the CIA SAFE project, a 7 year systems life beyond IOC 
is assumed. For the architecture life of SAFE, a fifteen (15) 
year estimate, beyond IOC, appears reasonable. In SAFE procure- 
ments, the systems life estimate will be used. This is because 
it is judged unrealistic to estimate most costs and benefits beyond 
the limited systems life. For example, major hardware upgrade 
costs, mainframe costs, and other support costs are exceptionally 
difficult to estimate in out-years. Vendors are reluctant to make 
proposals over extended time periods. Systems life, however, (e.g. 
to the first major mainframe upgrade) appears a reasonable period 

of been 
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Part IV. Value of Compatibility: Cost and Impact Breakdown 
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COST OF NON-COMPATIBILITY 


Cost Element No: A-l 

Cost Element : Increased Management Complexity and 

Program Risk 

Cost Qualitative Factor 

Evaluated Cost : 

Discussion 

A non- compatible SAFE system would involve an architecture 
unfamiliar to the majority of ODP Management. In addition to 
the "new" architecture aspects, ODP would become a multi- 
architecture operation which by itself increases management 
complexity. 

This added complexity in a multi-architecture environment 
is related to what is, in effect, a barrier inherent in archi- 
tecture differences. This barrier inhibits or even prevents 
the transfer of resources (i.e., people and hardware/software) 
between SAFE and other ODP centers. The alternative to resource 
transfers, the transfer of workload, is generally speaking also 
impractical in a multi-architecture environment. 

These constraints make management more difficult. Resources 
assignd to one architecture are generally not shared, limiting 
the usefulness of any resource "slack" or "cushion" available 
in the office. This requires better planning by management 
than would otherwise be required. The margin for error is 
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smaller and the risks are therefore higher. These risks 
diminished capability and a resulting impact on mission 
effectiveness . 


are 


Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6 



Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6 


COST OF NON-COMPATIBILITY 


Cost Element No 
Cost Element 
Cost 

Evaluated Cost 

Discussion : 

SAFE non- compatibility would present both advantages and 
disadvantages in the personnel management area. 

o Advantages . 

With a non-compatible SAFE, ODP would be supporting at 
least two distinct mainframe architectures. This would provide 
new challenges and opportunities for ODP personnel. Breadth 
of experience is an asset for a data processing professional. 

It can also be conjectured that a multi-architecture 
environment expands our recruiting pool in that 1) prospective 
employees with experience in either the ODP- or SAFE-supported 
architecture could more quickly contribute and therefore more 
easily be cost- justified and 2) the breadth of experience 
available in a multi-architecture environment could be a 
recruiting incentive. 

o Disadvantages . 

In a multi-architecture environment transfer of personnel 
between SAFE and ODP Processing would be a more complicated 
problem than with a single architecture: 


Impact on Personnel Management 
Qualitative Factor 
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a. Considerable training would he required (see Cost 
Element B-2) 

b. Productivity of transferred personnel would initially 
be lower even after training 

c. The pool of experienced people will be smaller. 

d. A reluctance of management to transfer personnel to 
work with a different architecture because of the drop 

in productivity. This constrains utilization of personnel 
resources. 

e. A reluctance of personnel to transfer to a position 
that requires familiarity with a different architecture 
(i.e., "fear of the unknown") . 
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Cost Element No: 
Cost Element : 
Cost : 

Evaluated Cost : : 


B-2 

Increased Vendor System Training 
$440K 


Discussion 

If SAFE is non-compatible with ODP , SAFE personnel, who 
will primarily come from the current ODP organization, will 
require intensive training on SAFE hardware and operating 
systems (i.e., the vendor system), in addition to SAFE appli- 
cations training. 

Table B-2 provides an estimate of minimum SAFE Government 
prof essional/ technical personnel post-IOC. The figures are 
a modification of current CSPO estimates. (1) 

Other personnel requiring SAFE vendor systems training 
will be ODP backup personnel. These ODP personnel are cross- 
trained in SAFE hardware and software and primarily have other 
ODP functions but serve as SAFE backup when required. The 
number of ODP backup personnel is also estimated in Table B-2. 


Analysis 

The Cost of Non-Compatibility is the cost of training in 
the new vendor hardware and operating system(s), SAFE personnel 
and ODP backup and their replacements over the systems life. 
Total personnel to be trained pre-IOC is 60 (44 SAFE and 16 

backup, from Table B-2) . An estimated 10 percent or 6 new 
personnel annually will require similar training throughout 
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the systems life (2)_ 

The vendor system training required is estimated as 20 

days/trainee ( = 160 hours/trainee) . The direct cost of this 

training is further estimated as $100/day. The total direct 

training cost is therefore $2000/trainee . 

During training, the employee is assumed compensated at 

(3) 

the current FY-79 ODP average annual salary of $21.37K, 

prorated over 160 hours of training (of 2080 available annually) 

(4) 

and adjusted for 40% government burden. 

Employee compensation during training - 
($21. 37K X 1.4 X 160/2080) = $2.3K 

The Cost of Non-Compatibility in the area of vendor system 
training is the total training cost, which is: (No. of Trainees) X 
(Direct Training Cost + Employee Compensation during Training) . 

For Pre-IOC training, this cost is: 

60 X ($2K + $2 . 3K) = $258K 

For training of replacements during the systems life (7 years) , 
the cost is: 

7 X 6 X ($2K + $2 . 3K) = $181K 

Therefore, the estimated systems life cost for vendor systems 
training is ($258K + $181K) = $439K 
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Footnotes to Cost Element No. B-2 

(1) Reference 2 includes an estimate of CIA SAFE personnel 
requirements. It indicates that 36 CIA SAFE "operations" 
personnel will be required, but excludes some (unspecified) 
software and engineering support to be done jointly with DIA. 

An additional 8 personnel ("Enhanced SAFE Staff") have been 
included in Table B-2. The functions of these additional 
personnel, though not directly addressed in Reference 2, appear 
to be most suitable for performance by government personnel. 

The resulting staff of 44 is considered for our purpose a 
minimum government level. 

It should not be inferred that the 44 personnel will be 
slotted in the SAFE Operations Group or even ODP (e.g. security 
personnel may be from the Office of Security). The 44 personnel, 
in fact, exceed the 33 ODP slots estimated for the SAFE 
Operations Group (See Reference 3) and the overall staffing 
estimate in the Consolidated SAFE Requirements Document (CSRD) , 
Reference 1. 

(2) Assumes 20 percent replacement rate of which half or 

10 percent require vendor system training. It is assumed the 
other 10 percent has vendor systems expertise through prior 
training or experience. 
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(3) From C/P&BG/MS/ODP . 

(4) 26% Standard Fringe Benefit Factors with 11% (est.) 

CIA G&A, see Reference 5, pages 24 & 44-49. Rounded to 40%. 
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Table B-2 

Estimated Minimum SAFE Government Personnel Requirements (Post-IOC) 


Job Category 


Title 


Operations 


Operations 
Performance Mgmt. 
Facilities/ Conf ig # Mgmt . 


aintenance 


B.l JHardware Mnt. 

B.2 Software Mnt. 

a) Systems Mnt. (Vendor) 

b) DBMS Mnt. 

c) BAFE Mnt. 



No. of Govt. Professional/Technical Personnel 


Enhanced 

S AFE Operations Group (1) 


c. 

Administration 

C.l 

Project Office Admin. 

C. 2 

Database Admin. 

C. 3 

Security (1) 

D. 

Development (1) 

D.l 

Systems Eng. (Planning 

D. 2 

Applications Dev. 

E. 

Training/Documentation (1) 




E.l 
E. 2 

— E jlIL 

1 TOTAL [ 44 j 16 

(1) Enhanced SAFE Operations Group personnel 

possibly SI^®MttM 0 KL ( tS e o e r P i t e 

are believed reasonable extensions of SAFE personnel requirements. & 
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COST OF NON-COMPATIBILITY 


Cost Element No: B-3 

Cost Element : Additional Personnel Requirements 
Cost : $4090K 

Evaluated Cost : 

Discussion 

In an H/S compatible environment, certain ODP Processing 
personnel could provide common support to both Processing and 
SAFE; these personnel are referred to as shareable . With a 
non-compatible SAFE, the common support of shareable personnel 
is not available and an increase in SAFE personnel requirements 
would result. 

Shareable Personnel resources are defined as those ODP 
professional or technical personnel (staff or contractor) 
supporting on-going ODP Processing activities whose work is 
directly applicable to SAFE at little or no additional cost. 

An example would be systems programming support in an H/S 
compatible environment. 

The architecture barrier present with a non-compatible 
SAFE interferes with the transfer of the work product of these 
Shareable Personnel. To make up for this loss, an equivalent 
number of personnel must be included as part of overall SAFE 
personnel requirements. It should be emphasized that these 
personnel are not the full complement of SAFE staff but are 
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additional to those that would otherwise be required in an 
H/S compatible environment. Additional Personnel for 
Non-Compatible SAFE are therefore defined as the estimated 
ODP staff or contractor personnel required to support a non- 
compatible SAFE minus estimated ODP personnel required to 
support an H/S compatible SAFE. In this analysis, the difference, 
i.e., the number of Additional Personnel for Non-Compatibility 
is assumed equal to the Shareable Personnel in an H/S compatible 
environment. 

Analysis 

Table B-3 presents an estimate of the Additional Personnel 
for Non-Compatibility (= Shareable Personnel in an H/S compatible 
environment) by job category. An estimated total of 13 addi- 
tional personnel are required annually in a non-compatible 
environment throughout the systems life. In fact, it may be 
argued that these additional personnel will be required through- 
out the architecture life. (Architecture life, as used herein, 

extends beyond systems life, to the time of system total re- 

( 1 ) 

procurement or redesign: i.e., an estimated 15 years). 

Since the goal of this analysis is to develop assessments 
suitable for use in proposal evaluation, the cost estimate is 
limited to the systems life (7 years) . 

In Appendix B-3, an average annual cost for the 13 addi- 
tional personnel is computed as $584K. This represents the 
cost of funding 13 positions at an approximate average govern- 
ment-contractor salary. Over the 7 year systems life, this is 
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$4 09 OK (undiscounted) . Thus the estimated cost of non- 
compatibility in the area of personnel requirements is 
$4090K (1979 dollars) . 


(1) See Appendix III, Part III: "Architecture Life vs. 
Systems Life." 
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Table B- 3: Estimate of Additional Personnel for Non-Compatible SAFE 


Job Category 

Additional Personnel 
for Non-Compatible SAFE 

Comments 

No. 

Title 

(=Shareabl.e Personnel 

(Comments below refer to difference in personnel requirements 

v/ H/S Compatible SAFE) 

between Non-Compatible SAFE and H/S Compatible SAFE) 

A. 

Operations 


j 

A. 1 

Operations 

2 

Technical Specialists required for SPD/OD interface 

A. 2 

Performance Mgmt. 

1 

(Already available for current IBM O/S's) 

Additional person for new architecture. 

A. 3 

Facilities/Config. Mgmt. 

1 

(Large body of expertise in ED/SEB on IBM H/S) 

Additional Config. Mgr. for new architecture. 

B. 

Maintenance 



B.l 

B. 2 

Hardware Hnt. 

Software Mnt. 

2 

IBM-compatible vendor interfaces being managed by existing staff. 
Additional staff required for new vendor interfaces associated w/ 
new architecture. 

a) 

Systems Mnt. (Vendor) 

6 

SPD currently performs this function for IBM O/S’s; new 

b) 

DBMS Mnt. 

'k 

systems programming group would be required. 

c) 

SAFE Mnt. 

* 

, 

C. 

Administration 



C.l 

Project Office Admin. 

* 

Additional person for new architecture. (Large body ot expertise In 
ED/SEB on IBM hardware; consolidated planning/procureraent possible 

C. 2 

Database Admin. 

* 

In H/S Compatible environment). 

C. 3 

Security 

* 


D. 

Development 



0.1 i 

Systems Eng. (Planning) 

l 


D. 2 

Applications Dev. 

* 


E. 

Training/Documentation 



E.l 

User Training 

A 


E.2 

System Training 

* 


E. 3 

Tech. Writing 

A 



TOTAL 

13 



♦Compatibility Is not judged to have an impact on personnel 
requirements. 
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Cost of Non-Compatibility: Cost Element B-3 


APPENDIX B-3 

Cost of Additional Personnel 
Required to Support a Non-Compatible SAFE 

TABLE 1; Computation of Average Salary of Additional Personnel 


Govt. Grade 

FY-79 

Govt. Salary 
(1) 

Burdened 
Govt. Salary 
(2) 

Contractor 

Salary 

(3) 

Avg . 
Salary 
(4) 

GS-11 

21. 8K 

30.5K; 

4 3 . 6K 

37. IK 

GS-12 

26. 2K 

36. 7K 

52. 4K 

44. 6K 

GS-13 

31. IK 

4 3 . 5K 

6 2. 2K 

52. 9K 

' 


(1) Assuming Step 5 

(2) 40% burden added to FY-79 Govt. Salary 

(3) 100% burden added to FY-79 Govt. Salary 

(4) Average of Burdened Govt. Salary and Contractor Salary 
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Cost of Non-Compatibility: Cost Element B-3 

Appendix B-3 (continued) 

Table 2: Estimated Annual Cost of Additional Personnel 



Job Category 

Annual 

Addi t iona 1 
Personnel 

Es t . 

Equivalent 
Govt. Grade 

FY-1979 

Avg. Salary/ 
Person 

Annua 1 
Cost 

No. 

Title 





A . 1 

Operations 

2 

GS-11 

37 . IK 

74. 2K 

A. 2 

Perf. Mgmt 

1 

GS-13 

52 . 9K 

52 . 9K 

A. 3 

Facilities 

1 

GS-11 

37 . IK 

37 . IK 

B. 1 

Hdwre. Mnt, 

2 

GS-11 

37. IK 

7 4. 2K 

B . 2a 

Sof twre . Mnt . 

( Sy s t eras) 

6 

3 GS-13 

3 GS-12 

52. 9K 

44. 6K 

158. 7K 
133. 8K 

D. 1 

1 

Sys. Eng. 

1 

GS-13 

52. 9K 

52. 9K 


13 

GRAND TOTAL 

$ 584K (1) 


(1) Annual cost of 14 additional personnel, in FY-79 dollars. 
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COST OF NON-COMPATIBILITY 


Cost Element No: C-l 

Cost Element : Limitations on Reconfiguration and 

Reutilization 

Cost : $490K 

Evaluated Cost : 

Discussion 

If the SAFE Center were non-compatible with other ODP 
centers, the transfer of hardware between centers would generally 
be impossible. Reconfiguration between centers includes the 
temporary transfer of equipment for test purposes and the per- 
manent re-allocation of equipment to satisfy higher priority 
requirements, improve performance and balance workload. 
Reutilization occurs when the requirement in one center for 
a hardware item no longer exists (i.e., equipment reaches the 
end of its systems life) . Opportunities for reutilization 
would then be explored within ODP (and throughout CIA) prior 
to release to GSA as excess to agency needs. Reutilization 
is really a special form of reconfiguration in which the equip- 
ment has reached the end of its systems life due to capacity 
limitations or technological obsolescence. 

Reconfiguration and reutilization (R/R) are currently 

routine activities within ODP. R/R is distinguished from 

( 1 ) 

emergency and (limited and full) disaster backup in that 
R/R is for long-term service improvement or configuration test. 
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Analysis 

A rough bound on the value of reutilization with an H/S 
compatible SAFE may be computed under the following assumptions: 

(1) SAFE Center hardware will not be reutilized (in another 
ODP center) until the end of systems life (by definition) . 

(.2) Unlike the other ODP centers, the SAFE Center will 
support a single high performance service; equipment that has 
reached the end of its systems life in the Ruffing or Special 
Centers will, generally speaking, not be suitable for SAFE 
operations for performance reasons . 

(3) Excluding workstations and printers, an estimate of 
the purchase price of the CIA SAFE IOC configuration is 
$6023K (1979 dollars) . (See Appendix C-l) . 

At the end of the systems life, it is estimated that the 
residual value of the SAFE hardware is 10% of the initial pur- 
chase price: i.e., 10% of $6023K or $602K. Furthermore, it 
is assumed that at the end of systems life, 50% of the SAFE 
equipment (by value) can be reutilized. Therefore, a rough 

estimate of the value of reutilization is 50% of $602K or 

( 1 ) 

approximately $30 OK. 

A similar approach may be used to bound the value of re- 
configuration. The following assumptions are made in this 
case : 

(1) SAFE being a single high priority /high performance 
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service will not divert any hardware prior to the end of 
systems life for use in other ODP centers (and thereby suffer 
degradation in SAFE performance) . 

(2) At the midpoint of systems life, SAFE hardware (ex- 
cluding workstations and printers) is valued at 5p % of the 
purchase price or $3012K. It is furthermore assumed that 25% of 
the SAFE equipment (by value) is swapped for higher performance 
Ruffing or Special Center equipment. This swapping (i.e., 
reconfiguration) results in a 25% increase in SAFE equipment 
capacity and no significant degradation in ODP service per- 
formance (as distinguished from equipment performance) . 

In line with the assumptions above, at the midpoint of 
systems life, reconfiguration provides a 25% increase in 
equipment value for 25% of the equipment, or: .25 X .25 X 
$3012K = $188K. Thus the value of reconfiguration may be 
roughly estimated as $188K. 

This admittedly is a crude approach that assumes no loss 

of value in the ODP centers receiving presumably lower per- 

( 2 ) 

formance equipment. 

The net value of reconfiguration and reutilization is 
$188K + $300K = $488K (1979 dollars). This figure should be 
taken as a rough guide only. 


(1) Theoretically, residual value is a government-wide (not 
agency-specific) concept. Therefore, SAFE hardware will have 
an estimated $602K residual value independent of whether 
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reutilization in ODP or the Agency is possible: i.e., the 
value accrues to the government not to an agency. (for example 
in a procurement evaluation, residual value is computed for all 
hardware irrespective of the real prospects for reutilization 
in an agency.) However, the approach followed above, though 
conceptually imperfect, does reflect the real-world benefit to 
ODP and the Agency. 

(2) Another major problem with this approach is that it fails 
to properly account for the interaction between reconfiguration 
and reutilization. A more detailed analysis was judged beyond 
the scope of this study. 
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Appendix C-l(a) 

Estimated Purchase Price of IBM-Compatible 
CIA SAFE IOC Configuration (exc. Workstations 
and Printers) 


STATINTL 

STATINTL 


The IOC configuration assumes a User Terminal Support 
subsystem sized for approximately 600 workstations; the cost 
of these 600 workstations (and associated printers) is 
excluded from the estimate. Three approaches are available 
for making this estimate: 

Approach 1 : Use of the Marketplace 

Proposals received in response to SAFE ADPE RFP would be 
examined. The lowest purchase price for a configuration that 
utilized IBM-compatible hardware would be selected. 

Approach II : Use of the IBM GSA Schedule 
The IBM GAS ADP Schedule would be used to price out the 
IOC configuration. 

Approach III : Use of th e Con figuration STATINTL 

Purchase Price 

m|^^^^^^^^|proposal (Reference 4 (b) ) prices out a sample 

SAFE IOC configuration using ^^^^^^^^^^^^lardware . Table 

1, Appendix C-l(b) is the basic cost data. The CIA SAFE IOC 

( 1 ) 

configuration purchase price is computed to be: $6023K. 

Approach I uses competitively-derived prices and is 

actually ideal. Prior to proposal evaluation, however, it is 

(2) 

clearly not possible. 
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Approach II, use of the IBM GSA ADP Schedule Price List 

provides an effective "ceiling" on a true competitively- 
derived cost. This approach will not be used because of the 
time involved in developing an IBM-compatible configuration. 

If more time were available, this could be pursued. 

Approach III uses the readily available con- STATINTL 

figuration costs as an approximation of the cost for the 
comparable IBM— compatible configuration. For convenience, this 
approach will actually be used. Therefore, 

The estimated cost of an IBM-compatible SAFE IOC 
configuration, for the purposes of this analysis is: $6023K 
(1979 dollars) . 


(1) Ignoring the DIA subsystem costs, the workstation and 
printer costs, and using only half of the User Terminal Support 
subsystem (i.e., UTSC — Item 7) cost. 

(2) This approach is a candidate for use in the actual RFP 
evaluation if the value of IBM-compatibility is actually 
"folded-in" to the evaluation. 
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Appendix C-l lb) 

Estimated Purchase Price and Systems Life Cost of 
CIA SAFE IOC Configuration 


Table 1 : 

Purchase 
SAFE IOC 

Price and Monthly 
Configuration, (t) 

Maintenance of CIA 

SAFE 

ADPE 


Purchase 

Monthly 

Item 

Amount 

Maintenance 

1 - 

SCMC 

$665. 2K 

$ 2,523 

7 - 

UTSC x .5 

912. 6K 

3,682 

8 - 

MAPC 

694. 3K 

2,712 

9 - 

DCM 1 

3403. 5K 

12,662 

12 - 

DCM 2 

347. IK 

1,329 


TOTAL 

$6023K 

$22,908 


The systems life cost of the CIA SAFE IOC configuration 
(excluding workstations and printers) may be approximated by 
assuming a seven year (84 month) systems life for the entire 
IOC configuration. Therefore, the (undiscounted) systems life 
cost is: 

Systems Life Cost = Purchase Price + Systems Life (months) 

x Monthly Maintenance 
= $6023K + 84 x 22. 9K 
= $7947K (1979 dollars) 
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Footnote to Appendex C-l(b) 

STATINTL 

(1) From SAFE Cost Proposal, page 5-3 (Reference 4(a)). 
■■■hardware configuration; excludes DIA, workstations 
and printers and .5 x UTSC cost (UTSC subsystem is downsized 
50% to reflect contract vice proposal workstation quantities; 
UTSC configuration costed will support 600 terminals.) 
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COST OF NON-COMPATIBILITY 


Cost Element No: C-2 

Cost Element : Unavailability of Emergency and Limited 

Disaster Hardware Backup 
Cost : $40K 

Evaluated Cost : - 
Discussion 

An emergency situation for our purposes is defined as an 
item of SAFE hardware rendered inoperative for a prolonged 
ps^iod of time. The problem is due to a routine malfunction 
and the delay is due to troubleshooting or parts supply 
difficulties . 

A limited disaster as used herein is defined as a small 
number of SAFE hardware items rendered inoperative due to 
fire , flood, explosion, physical damage, etc. Routine equipment 
malfunction is excluded. The limited disaster may leave the 
SAFE system operative, but in a degraded mode. The equipment 
affected will generally require extensive refurbishment or 
replacement. In a limited disaster situation it is possible 
that hardware could be used from another ODP center. The 
equipment transfer could generally be performed sooner than a 
vendor replacement could be supplied. 

A limited disaster is distinguished from a full disaster 
where a major portion of the SAFE Center is damaged and the 
SAFE system is inoperative (see Cost Element D-3 (b) ) 
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The above definition also applies to the other ODP 
centers with SAFE hardware being used for backup. A non- 
compatible SAFE renders emergency and limited disaster hard- 
ware backup impossible. 

Analysis 

The following assumptions will be made in order to 
estimate the cost impact of the unavailability of emergency 
and disaster backup: 

(1) Because SAFE is a high priority/high performance single 
service, SAFE hardware will not be available for extended 
periods to provide backup for the ODP Ruffing and Special 
Centers . 

(2) With an H/S compatible SAFE, the extensive hardware 
in the Ruffing and Special Centers would be a candidate for 
SAFE emergency and limited disaster backup. 

(3) The SAFE backup is assumed required for 10% of the 
IOC configuration (by value) for 5% of the systems life (4 out 
of 84 months) . 

The value of the backup required may then be estimated as 
5% of the systems life cost of the 10% of the system requiring 
backup. An estimate of the IBM-compatible CIA SAFE IOC con- 
figuration systems life cost is provided in Appendix C-l (b) : 
i.e., $7947K. The value of the backup provided by ODP Pro- 
cessing may be computed by pro-rating this systems life cost: 
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Value of SAFE Emergency and 

Limited Disaster Backup = .05 x .1 x $7947K 

= $40K (1979 dollars) 
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COST OF NON-COMPATIBILITY 


Cost Element No : C-3 

Cost Element : Consolidated Procurement 

Cost : No Cost Impact or Impact can be Evaluated 

in Procurement 

Evaluated Cost : 

Discussion 

An H/S compatible SAFE opens up the possibility of ODP- 
wide consolidated procurement of hardware, software and main- 
tenance services. Consolidated procurement may permit 
government cost saving through a favorable vendor pricing 
structure stemming from economies of scale. The larger single 
vendor hardware/software base possible in an H/S compatible 
environment increases government leverage , which may lead to 
improved vendor maintenance performance. Another possible 
benefit of a larger single vendor base (as compared with a 
multi -vendor base that would generally occur in non-compatible 
environment) is savings in the total floor space required for 
maintenance support and a reduction in total vendor maintenance 
personnel (with a savings in attendant security clearance pro- 
cessing costs and other government administrative support costs) . 
Thus an H/S compatible SAFE may lead to: 

1) ODP-wide consolidated hardware procurement encompassing 
larger quantities of equipment than separate procurements 
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as would generally be required in a multi-architecture 
environment . 

2) Consolidated maintenance contracts covering larger 
quantities of equipment than would be the case in a 
multi-architecture environment. Miscellaneous resource 
savings (space, etc.) due to the possibilities of a large 
single vendor base and improved leverage over the 
maintenance vendor. 

3) Consolidated software procurements covering the pur- 
chase, licensing and maintenance of multiple copies of 
software . 

Analysis 

Assessing the government cost savings in the above situations 
is a complex problem that is significantly related to procurement 
policy and practice. ODP experience indicates that vendor 
pricing has not been overly sensitive to volume except for 
some hardware procurement situations and some software licensing 
agreements . 

Typically, vendor GSA ADP Schedules show purchase and 

maintenance prices on a "per box" basis and software licensing 

(1) 

and maintenance on a "per CPU" basis. Furthermore, assumptions 

about savings from vendor volume discounts are probably true 

within a specific vendor's pricing structure; however, between 

( 2 ) 

vendors, actual price comparisons are required. 
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That being the case, loss of consolidated procurement, 
through non-compatibility, will have an unknown cost impact. 
Assuming cost benefits to be associated with consolidated pro- 
curement would be an example of "prejudging the marketplace." 
The SAFE procurement itself can be used to determine vendor 
pricing practices by requiring vendors to propose the hardware/ 
software and maintenance services required over the systems 

life. No marketplace inferences need or should be made 

( 3 ) 

external to the initial SAFE procurement. 

In a non-compatible environment, volume discounts through 

consolidated procurements and maintenance, and benefits due 

to a large single vendor base would, generally speaking, not 

( 4) 

be possible. The impact of the loss of these savings and 

benefits is assessed in more detail below: 

1) Consolidated Hardware Procurements . Consolidated 

hardware procurements require H/S compatibility and 

common requirements . The SAFE hardware covered in 

the existing SAFE contract will be procured independent 

( 5 ) ' 

of ODP Ruffing Center and Special Center requirements. 
Presuming H/S compatibility and common requirements , 
subsequent procurements, as yet unspecified, could be 
consolidated. These procurements would most likely 

(6) 

involve peripherals, primarily disks and terminals. 
Currently quantities are unknown on both the SAFE 
and ODP Processing sides. 
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As discussed earlier, though favorable pricing for a 
consolidated procurement is a reasonable assumption, 
it is far from a certainty. Use of anticipated cost 
saving from unspecified future consolidated procure- 
ment as a factor in an RFP evaluation or procurement 

(7) 

decision would be a questionable practice. 

2) Consolidated Hardware Maintenance . Consolidated 

maintenance requires an additional constraint to 

H/S compatibility: identical vendors. While identical 

vendors are likely in the mainframe area (i.e., ODP 

has several CPU's from two of the major IBM-compatible 

vendors, , it is less certain in the 

peripheral area. ODP currently has a policy of OEM 

( 8 ) 

maintenance. OEM’s have not, as mentioned earlier, 

provided volume discounts, but priced on a "per box" 

basis. Maintenance for the initial SAFE hardware will 

be procured in the RFP. Maintenance prices will there- 

(9) 

fore be evaluated directly. Maintenance for equipment 
subsequently procured might be less expensive if equipment 
were from an in— house vendor, but as this argument woul be 
questionable for restricting competition in a procurement, 
it should not be considered as a factor in valuing the 
impact of non-compatibility. 

In a similar vein to the above, maintenance vendor space 
requirements can be evaluated (i.e., costed) directly in 
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the initial SAFE RFP. Procurement practice would require 
the space provided not be unduly limited, which would 
result in restricting the competition to in-house vendors. 
Arguments similar to the above discussion on consolidated 
maintenance pricing for follow-on SAFE procurement would 
dictate that hypothetical maintenance vendor space savings 
in future procurements not be considered an impact of non- 
compatibility. Procurement practice also requires, except 
in unusual circumstances, that security clearance and 
administrative support costs should not be allowed to 
restrict competition. 

An H/S compatible SAFE may lead to a large single vendor 

base which improves government "leverage" over the vendor 

and may lead to improved hardware availability. Though 

the above is "logical" and "common sense," it is purely 
(10) 

conjectural and should not be used as a basis for govern- 
ment decisions. Hardware availability requirements should 
be specified directly in the RFP and vendor capabilities 
evaluated, with penalties for non-performance. 

3) . Consolidated Software Procurement and Maintenance . 

Most vendor software is priced on a "per CPU" basis except 
where tightly-coupled networks are involved (e.g., JES3 ) . 
Certain types of independent vendor software, however, are 
discounted when multiple copies are ordered. System soft- 
ware initially procured for SAFE will probably be evaluated in 
the RFP. In an H/S compatible environment, subsequent pro- 
curements of software for SAFE and other ODP centers from 
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independent software vendors and from the mainframe hard- 
ware vendors might reflect discounts due to copies running 
on other ODP CPU's. As in the discussion of consolidated 
hardware and consolidated maintenance above, the benefits 

are largely hypothetical and will not be considered in 

(ID 

evaluating the impact of compatibility. 
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Footnotes for Cost Element No. C-3 

(1) Tightly-coupled networks (like JES3) often are an 
exception to "per CPU" licensing; the network is priced as 
one CUP (though possibly containing several CPU's. 

(2) That is, four units of vendor X's equipment are not 
necessarily cheaper than two units of vendor X's equipment 
plus two units of vendor Y's. It depends, obviously, on the 
cost of vendor Y's equipment. 

(3) The potential for saving on procurements subsequent to 
the initial SAFE procurement is a more complicated issue and 
is discussed in the following sections. 

(4) This ignores the possibility of a multi-architecture con- 
solidated procurement; e.g., vendors with multi-architecture 
product lines or third party maintenance or leasing firms 
could respond to multi-architecture consolidated procurements. 

(5) With the possible exception of CRT terminals. 

(6) Note that consolidated terminal procurement may be possible 
even without H/S compatibility. 

(7) It should be noted that Computer System Division at NPIC 
is a Uni vac-compatible operation. Therefore, e.g., if SAFE 
were Uni vac-compatible , there exists the possibility of 
consolidated procurements between NPIC and SAFE. (ODP has 

already procured CRT terminals in a consolidated procurement 
with NPIC.) 


Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6 



Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6 


(8) This is currently under study within ODP Processing. 

(9) The possibility of a vendor providing a maintenance price 
reduction on ODP Processing hardware as well as SAFE hardware, . 
and therefore not subject to evaluation in the SAFE RFP is 
judged small, primarily because it would be in the best interests 
of the vendor to reflect all discounts in the RFP. 

(10) We know of no study that demonstrates a correlation between 
the size of a vendor base in an installation and equipment 
availability. 

(11) For example, due the H/S compatibility and a multiple copies 
requirement in ODP , an independent software vendor might provide 
discounts from the single copy price of the software. However, 
another hardware equipment vendor might provide a similar package 
free, or the vendor might provide different versions which 
execute on different architectures and therefore discounts might 
be available for multiple copies irrespective of architecture, etc. 
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COST OF NON-COMPATIBILITY 


Cost Element No: C-4 

Cost Element : Software Exchange Limitations 
Cost : $4 70K 

Evaluated Cost : - 

Discussion 

With a H/S compatible architecture, government-owned 
software could be exchanged between SAFE and other ODP centers. 

In a non-compatible environment software exchange would be either 
impossible or require an expensive conversion. Government- 
owned software suitable for exchange may be divided into two 
categories: 

1) Contractor-developed SAFE software for which ODP Ruffing 
or Special Center requirements exist; 

2) 0DP-, user-, or contractor-developed software executing 
in the Ruffing or Special Center that satisfies a SAFE 
requirement. 

An example of the former category is SAFE text search 

software. ODP personnel have indicated that a DDO text search 

requirement similar to SAFE’S is under discussion. An example 

of software in the latter category might be GIM II for structured 

( 2 ) 

DBMS requirements or an econometric model developed by the 

(3) 

Office of Economic Research. 
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Analysis 

In the first category, it is estimated that 3.5% of SAFE 

contractor-developed software will be exchanged with other ODP 
(4) 

center. Introduction of this SAFE software will occur over 
the seven year systems life at an estimated rate of .5% annually. 
In a non— compatible environment, this software cannot simply be 
exchanged but must be either independently developed or converted. 
The estimated cost of independent development of the exchanged 
software would be : 

$313K = 3.5% of $8950K (cost of contractor— developed 
(5) 

software) 

Assuming 50% of the exchanged software (by value) requires 
development (i.e. , $157K) and the remaining software is suitable 
for conversion at 50% of the development cost (i.e., .5 x .5 x 
$313K = $78K) , the effective value of exchanged software is : 

$157K + $78K = $235K. 

Considering the second category of software exchange : it 
is estimated that 3.5% of the SAFE software scheduled for con- 
tractor development will be available from ODP in a compatible 

(4) 

architecture environment. The resulting saving will occur 

IOC. This equates to a $235K estimated savings (see above 
computation). During systems life, the hard SAFE requirement 
for additional ODP-developed software is judged small. ODP 
mainframes will be accessible to SAFE users through the SAFE-ODP 
communications link. Therefore, stand-alone ODP software 
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packages (e.g. , econometric models) will be available to SAFE 
users independent of SAFE architecture. 

The total value of software exchange is the sum of the 
value in the two categories discussed above. The final estimate 
is therefore $470K (1979 dollars) . 
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Footnotes to Cost Element No. C-4 

(1) A distinction is made between licensed software and govern- 
ment-owned because the former generally incurs a separate cost 
when run on additional mainframes and, if available, can be 
procured irrespective of arthitecture compatibility. 

(2) GIM II is government-owned and therefore free; with an N/C 
architecture an alternative would be procurement of a comparable 
vendor DBMS package. 

(3) An N/C architecture would require a conversion. 

(4) The estimated 3.5% rate of software exchange is based on 
1) low rate of ODP-or user-developed software exchanged between 
the ODP Ruffing and Special Center, 2) historical lack of success 
in fostering exchange in the federal government (e.g. , poor 
performance of Federal Software Exchange Program) . 

(5) See Appendix C-4 for the estimated cost of contractor-developed 
SAFE s o f twar e . 
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Appendix C-4 : Estimated Cost of Contractor-Developed 

SAFE Software 

The approximate cost of contractor-developed SAFE software 
is computed by first estimating the number of Lines of Source Code, 
converting to Project Man-Hours and then using an estimated Dollars 
per Man-Hour figure to generate the software development cost. 

The stepwise procedure follows: 

Step 1: Computation of the Number of Lines of Contractor- 

developed Source Code (i.e., higher order language 
(HOL) or assembly language (ALC) ) : 

The contractor has provided an estimate of 44 5K 

„ , . _ ( 1 ) 

deliverable, executable machine instructions (DEMI's) 

We assume that the DEMI's are generated 50% (222. 5K) 

from HOL source code and 50% (222. 5K) from ALC source 

code. Assuming a conservative 2 DEMI's per line of HOL 

source, this implies 111.25K lines of HOL source (i.e., 

222. 5K DEMI's -r 2 lines HOL source/DEMI) and 222. 5K 

lines of ALC source for a total of 333, 75K Lines of 

Source Code. 

Step 2: Computation of Number of Man-Hours of Total Project 

Effort: Using 173.3 Man-Hours/Man-Mont h (i.e., 2080 

Hours/Year t 12) and 150 Lines of Source Code per Man- 

( 2 ) 

Month of Total Project Effort, we compute the Man- 
Hours of Total Project Effort: 333. 75K Lines Source 
Code X (173.3 t 150) Man-Hours/Line of Source Code = 

385 . 6K Man-Hours . 
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Step 3: Final Computation of Estimated Cost of Contractor- 

developed Software : 


Estimated Cost of 
Contractor-developed 

Software = 385. 6K Man-Hours x $23. 2 /Man -Hour 

Total Project Effort (3) 


= $8950K (1979 dollars) 
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STATINTL 


STATINTL 


Footnotes to Appendix C-4 


(1) ^^Bestimate from Proposal, Vol. I, pages 1-19 (Reference 

4 (a) ) . 

(2) A lower quartile total effort productivity estimate from 
Walston and Felix, IBM Systems Journa l, "A Method of 
Programming Measurement and Estimation," 1977, (Reference 
5) . 

(3) Derived from proprietary data: 

Tota^rmec^jabo^oUar^^Total Project Labor Hours 

in 1979 dollars) . 
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COST OF NON-COMPATIBILITY 

Cost Element No. : D 

Cost Element : Technical Barriers to Load Sharing 

Cost : $500K + Other Factors (see sub-elements) 

Evaluated Cost : 

Discussion 

Load Sharing may be divided into several categories . Other 
cost elements are associated with the cost of transferring 
resources (people, hardware/software) between non-compatible 
architectures. Load Sharing is an alternate approach (i.e., 
transferring the workload) but it too is generally rendered 
impractical by non-compatibility. 

Several categories of load sharing may be defined: 

D-l. Routine Production Load Sharing . 

This category implies SAFE production software is explicitly 
designed to run in the ODP Ruffing Center. Software in this 
category is not considered part of the SAFE workload (i.e., 

SAFE is not necessarily sized to process it). In fact, SAFE 
may not be able to process this software at all. (This would 
be the case with a non-compatible architecture.) This concept 
also encompasses the reverse situation: ODP production software 
designed to run in the SAFE Center. 

D-2 . Routine Development Load Sharing 

SAFE systems and/or applications software development (post- 
IOC) is routinely performed on ODP mainframes. This activity 
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is primarily prime-shift activity associated with maintenance 
and enhancements. 

D-3 . Backup Load Sharing 

Backup Load Sharing is subdivided into two major sub- 
categories: Overflow and Disaster. 

D-3 (a) Overflow Load Sharing 

Overflow load sharing implies that under peak load 
conditions (e.g. , backlog) workload (primarily batch) 
could be shifted between SAFE and other ODP centers. 

D-3 (b) Disaster Backup 

Disaster backup implies the capability to transfer 
critical workload between ODP centers in the event of the 
unavailability of a major service. Unavailability of 
service as defined herein is considered to be long-term 
and due to a power outage, fire, flood, etc. 

The impact of SAFE non-compatibility on the various cate- 
gories of load sharing is discussed in the following cost sub- 
elements. The costs presented above are the aggregate costs 
associated with the load sharing categories (i.e., the sum of 
the load sharing sub-element costs that follow) . 
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COST OF NON-COMPATIBILITY 

Cost Sub-element No.: D-l 

Cost Sub-element : Routine Production Load Sharing 

Cost : No Impact 

Evaluated Cost : 

Discussion 

Batch processing support of SAFE in the Ruffing Center 

would be more straightforward in an H/S compatible environment. 

( 1 ) 

The SAFE CSRD, however, includes only one reference to offline 
batch processing requiring Ruffing Center support. This is in 
the SAFE Management Information System (MIS) area. SAFE is 
designed as an almost exclusively online system; e.g., database 
update is on an online continuous basis. Therefore, batch pro- 
cessing requirements and, in particular, offline batch require- 
ments, are envisioned as small. Any benefits in the batch 
processing area associated with H/S compatibility would 
correspondingly be small. 

Two additional factors minimize this cost sub-element: 

1. The SAFE dual maxi processors in off-peak periods 
(primarily night) could no doubt provide a substantial batch 
processing capability within SAFE. 

2. Any routine offline batch processing hard requirement 
could be satisfied by applications programs specifically 
designed to run on Ruffing Center mainframes. This approach 
would also permit ODP applications programmers to support SAFE 
without substantial special SAFE architecture training. 
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Because of adequate non-prime shift Ruffing Center 
capability, the reverse situation (i.e., routine ODP production 
assigned to the SAFE Center) should not be necessary. 

(1) Consolidated SAFE Requirements Document (Reference 1) 
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COST OF NON-COMPATIBILITY 


Cost Sub-element No: D-2 

Cost Sub-element : Routine Development Load Sharing 

Cost : No Impact/Impact can be Evaluated in 

Procurement 

Evaluated Cost : 

Discussion 

With an H/S compatible SAFE, ODP Ruffing Center systems 

(e.g., VM) could be used for prime-shift SAFE development 

post-IOC, (primarily systems and applications maintenance and 

enhancements). With a non-compatible SAFE, development of 

higher-order language (HOL) programs for SAFE is technically 

( 1 ) 

feasible on ODP systems, though clearly inefficient. 

The proposed SAFE architecture has two levels of main- 
frames: so-called midi and maxi. At least one of the less 

expensive midi processors will be procured for backup and 
therefore could generally be used as a prime-shift development 
machine. If the maxi and midi are homogeneous (i.e., compatible 
in hardware and software) , use of the backup midi should meet 
system-wide development requirements. If the maxi and midi 
are not compatible , a separate , probably scaled-down version 
of the maxi might be required for prime-shift development. 

If a prime-shift development machine was not available 
(either through use of the midi in a homogeneous maxi-midi 
environment or through use of Ruffing Center mainframes) , the 
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vendor could be required to propose an additional development 
mainframe, sized to support a government specified development 
load. Thus this cost sub-element could be handled directly 
in the procurement and not require an explicit government 
estimate of the cost of a development machine. 

Recent CSPO analysis has indicated a significant cost 
saving associated with a homogeneous maxi-midi environment. 
Assuming homogeneity, because of the availability of the 
backup for development, non-compatibility is estimated in 
this category as having no cost impact. If homogeneity is 
not the case, this cost impact can be evaluated, as discussed 
above, directly in the SAFE ADPE procurement. 


(1) Development could be accomplished through the use of 
emulators, cross-compilers or the ODP language most similar 
to the SAFE HOL. These surrogate approaches are poor sub- 
stitutes for development using a system compatible with SAFE. 
Under the surrogate approach, extensive "live" SAFE time would 
be required for further development, conversion, system 
integration, test. etc. 
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COST OF NON-COMPATIBILITY 

Cost Sub-element No: D-3(a) 

Cost Sub-element : Backup Load Sharing (Overflow Load 

Sharing) 

Cost : $250K 

Evaluated Cost : 

Discussion 

Overflow load sharing would, in certain circumstances, 

be possible with an H/S compatible SAFE; i.e., under peak load 

conditions workload (primarily batch) could be shifted among 

(1) 

ODP centers. 

In a practical sense, however, the requirement for over- 
flow load sharing between SAFE and other ODP centers is judged 
small. SAFE is almost exclusively an online system; its 
unique system architecture (as distinguished from mainframe 
architecture) would render infeasible the off-loading of SAFE 
online tasks. In addition, the SAFE batch workload is very 

limited. SAFE processing capacity should be more than adequate 

( 2 ) 

to handle SAFE batch workload during non-prime time. 

During prime-time, there will be little excess SAFE capa- 

(3) 

city for processing ODP overflow batch or online workload. 

In non-prime time, the available capacity in the SAFE Center 

should increase. However, the same is true in the Ruffing and 

(4) 

Special Centers , and the requirement for overflow load sharing 
should be minimal. In addition, the Special Center can and 
occasionally does serve as an outlet for Ruffing Center overflow. 
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Overflow load sharing, only possible in an H/S compatible 
environment, is therefore judged of small value to ODP. 

An. estimate of the value of overflow load sharing is 5% 
of the systems life cost of an IBM-compatible SAFE dual maxi 
processor (i.e., the Document/Catalog Management/Text Search 
Management/Index Search Management Subsystem) . The underlying 
assumption is that 5% of an IBM-compatible dual maxi processor 
would be used to process Ruffing Center overflow (e.g., 10% of 
processor capacity during the non-prime shift) . An estimate 
of $4926K is developed in Appendix D-3(a) for the systems life 
cost of the dual maxi processor configuration. 

Therefore, the value of compatibility for over load- 
sharing is estimated as 5% of $4926K or $246K (1979 dollars) . 


(1) This discussion of the potential for load sharing 

intentionally ignores security issues inherent in inter-center 

/ 

load sharing. 

(2) The batch workload identified at this time (e.g., the SAFE 
Management Information System) is not time-sensitive. SAFE will 
be sized to handle prime-time online loads. During non-prime 
time excess capacity for batch processing should routinely be 
available. 


Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6 



Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6 




(3) As in the reverse situation, the routine off-loading of 
Ruffing Center online overflow (e.g., selective GIMS data- 
bases) would be a difficult technical task. 

(4) Utilizing this non-prime time capacity might require re 
configuring ("downsizing") ODP online services; e.g., trans- 
ferring VM from the IBM 3033 to the IBM 370/158. 

(5) Special Center overflow is negligible. 
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Appendix D-3 (a) : Estimate of the Cost of an IBM-compatible 

Dual Maxi Processor Configuration, Suitable 
for Backup Load Sharing 

In the SAFE System, the Document/Catalog Management/Text 
Search Management/Index Search Management (DCM/TSM/ISM) Sub- 
system is planned as a dual maxi processor. If it were IBM- 
compatible, as are the ODP Ruffing and Special Centers, there 
would be the possibility of backup load sharing. in this 
appendix, an approximate systems life cost for an IBM- 
compatible dual maxi processor is developed. The value of 
IBM-compatibility for backup load sharing is estimated as the 
percentage of an IBM-compatible dual maxi processor subsystem 
resource used applied to the cost of the subsystem. 

Table 1 details the dual maxi processor configuration. 
Three approaches to estimating the cost of an IBM-compatible 
dual maxi processor configuration are now described: 

° Approach I : Use of the Marketplace. 

Proposals received in response to SAFE ADPE RFP 
would be examined. The dual maxi processor con- 
figuration with the lowest overall evaluated cost 
that utilized IBM— compatible hardware would be 
selected. 

° Approach II : Use of the IBM GSA Schedule 

The IBM GSA ADP Schedule Price List would be used 
to cost out the dual maxi processor configuration 
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STATINTL 


STATINTL 


° Approach III : Use of Univac Configuration Cost 

The Univac dual maxi processor configuration is costed 
out in the^^^|Cost Proposal (Reference 4(b)). Table. 

1 (attached) from the proposal summarizes the Univac 
configuration cost. The estimate is approximately 
$3750K. The maintenance cost for the configuration is 
$14K/month over the systems life (pg. 5. -3, Cost 
Proposal, Reference 4(b)). Total cost over the systems 
life (7 years) is $4926K. 


Approach I uses competitively-derived costs and is actually 

ideal. Prior to proposal evaluation, however, it is clearly 

( 2 ) 

not possible. 

Approach II, use of the IBM GSA ADP Schedule Price List 
provides an effective "ceiling" on a true competitively-derived 
cost. This approach will not be used because of the time in- 
volved in developing a complete IBM-compatible configuration. 

If more time were available this could be pursued. 

Approach III uses the readily available Univac configuration 
costs as an approximation of the cost for the comparable IBM- 
compatible configuration. For convenience, this approach will 
be followed. Therefore, 

The estimated cost of an IBM-compatible dual maxi processor 
configuration is = $4926K (1979 dollars). 
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TABLE 1. Dual Maxi Processor Configuration and Univac 
Implementation Cost * 


1.1. 1.1.7 DCM/ADPE MAXI, DUAL PROCESSOR, 4M BYTES 


BASIS: 




DESCRIPTION 

ARCHITECTURE 

REPORT 

QTY. 

TOTAL 

BIO 

QTY. 

was 

sue 

NO. 

1. PROCESSOR COMPONENTS 

1 LOT 

1 LOT 

-1 

2. TAPE CONTROLLER 

1 

2d) 

-3 

3. TAPE DRIVES 

2 

2 

-2 

4. CARD READER 

0 

1(2) 

-3 

5, LINE PRINTER 

0 


-4 

6. DISK SUBSYSTEM-CONTROLLERS AND 

SHARED PROCESSOR l/F 

4*6-10 

10 

-6 

7. DISK SUBSYSTEM DISK DRIVES WITH 

DUAL ACCESS 

orrvi mrs mai* . 

AT 300 MB 

15 AT 2x600 MO 

-6 


(1) REDUNDANT UNIT TO IMPROVE AVAILABILITY 

(2) REQUIRED FOR DEVELOPMENT AND BY MANUFACTURER FOR SUPPORT 


WB55_ 

PART NO. 

NAME 

111171 

3032-91 

PROCESSOR 

111171 

3032-00 

PROCESSOR EXPANSION 

111171 

3033-96 

JOU EXPANSION 

111171 

1923-00 

10 CHANNEL EXPANSION 

111171 

F1C6601 

WORD CHANNEL MODULE 

111171 

F 2350-99 

MEMORY EXPANSION 

111171 

F3137-O0 

REMOTE CONTROL PANEL 

111171 

2626-00 

SUBSYSTEM AVAILABILITY UNIT 

111171 

8008-08 

MOTOR ALTERNATOR 

111172 

6017-00 

TAPE CONTROL 

111172 

F 0860.09 

SIMULTANEOUS OPERATION 

111172 

roazo-oo 

800 BPI 

111172 

f 

DUAL CHANNEL 

111172 

0862 04 

TAPE DRIVE 

111172 

F 1319 00 

DUAL ACCESS 

111172 

C 1609 02 

INTERFACE 6017 

111172 

F 0037 94 

DUAL DENSITY 

111173 

0716-02 

CARD READER (W/CTL) 

111174 

0776-02 

PRINTER (W/CTU 

111174 

F 22 1609 

PRINTER CARTRIDGE 

111175 

4600 

DISK CONTROL 

111175 

SPI 

SHARED PROC INTERFACE 

111176 

6860B2 

DISK DRIVE (2X600MB) 

111176 

90CO 

DUAL PORT 


VENDOR 

WIT 

PRICE**) 

QUANTITY 

EXTENDS 

PRICE 

UNIVAC 

1,216,268 

1 

1,216,268 

UNIVAC 

458,0445 

1 

468,040 

UNIVAC 

283,119 

1 

263,116 

UNIVAC 

7,905 

2 

15,610 

UNIVAC 

40,656 

4 

162,224 

UNIVAC 

150,000 

1 

150,000 

UNIVAC 

765 

1 

785 

UNIVAC 

58,620 

1 

59,520 

UNIVAC 

16,600 

1 

16,500 

UNIVAC 

21,420 

1 

21,420 

UNIVAC 

16,«S4 

1 

15,984 

UNIVAC 

4.320 

2 

8,840 

UNIVAC 

3,312 

2 

6,824 

UNIVAC 

18,824 

2 

33,043 

UNIVAC 

1,838 

2 

3,672 

UNIVAC 

N/C 

2 

0 

UNIVAC 

1,638 

2 

3,672 

UNIVAC 

11,828 

1 

11,626 

UNIVAC 

36.010 

1 

35,010 

UNIVAC 

1,000 

1 

1.000 

INTERSCI 

57,850 

10 

578,500 

intersci 

3,830 

10 

38,330 

SfC 

42,449 

16 

638,735 

STC 

Ml 

15 

14,115 



TOTAL 

$3,750,674 


<3) LIST PRICE LESS 26% DISCOUNT FOR UNIVAC UNITS 


STATINTL 


Figure 5. 3 1 Traceability DCM/TSM AOPE 

* Frorr^^MsAFE Proposal, Vol. II, "Cost," dated 16 March 1979, 
(SAF^^H“i002-3/79) 

5-53 
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Footnotes to Appendix D-3 (a) : 

(1) See Cost Element D, "Technical Barrier to Load Sharing," 
for a definition of backup load sharing. 

(2) This approach is a candidate for use in the RFP evaluation 

if the value of IBM-compatibility is "folded-in" to the evaluation. 
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that both centers were rendered inoperative an H/S compatible 
SAFE would be the only in-house backup. 

During non-prime shift an H/S compatible SAFE could process 
Agency batch workload in the event of a disaster. Only limited 
prime-shift SAFE processing capacity, however, would be avail- 
able. ODP online systems such as GIM II and VM could, in theory, 

be brought up under an H/S compatible SAFE. If SAFE were not 

( 3 ) 

accessible from general-purpose ODP terminals in a disaster 
situation, available SAFE terminals could be used for critical 
tasks . 

The related problem is the use of the Ruffing and Special 

Centers for disaster backup to SAFE. Because of the uniqueness 

of SAFE system architecture (as distinguished from mainframe 

architecture) , it appears technically infeasible to back up 

( 4 ) 

SAFE online functions in the Ruffing or Special Center. 

It is possible that special purpose backup software could be 

developed to provide a limited subset of SAFE capabilities 

( 5 ) 

in the Ruffing Center. This would require an unknown but 
significant development effort. There would probably be some 
advantage if the centers were H/S compatible in developing 
special purpose software. However, it is probably true that 
special purpose software could be developed even with different 
architectures. Without the required development activity, the 
value of the Ruffing Center as a significant SAFE backup is 
judged small. 
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COST OF NON-COMPATIBILITY 

Cost Sub-element No. : D- 3(b) 

Cost Sub-element : Backup Load Sharing (Disaster Backup) 

Cost : $250K 

Evaluated Cost : 

Discussion 

Disaster backup would be possible in certain circumstances 

( 1 ) 

with an H/S compatible SAFE. Under the assumption of a major 
catastrophe in the Ruffing or Special Center, batch workload 
could be processed by SAFE during non-prime shift. It is also 
possible that with an appropriate development effort, ODP on- 
line systems (e.g., GIM II, VM) could also be brought up on a 
SAFE processor during non-prime shift. In the event of a 
disaster, some SAFE functions could be supported in the Ruffing 
Center through special purpose software. This type of backup, 
however , would not be dependent on SAFE architecture . 

Currently, it is generally believed that the Ruffing and 

Special Center provide at least partial disaster backup for 

(2) 

each other, since they are H/S compatible centers. The 
major drawbacks to successful backup would be the limited 
processing and communications capacity in the Special Center. 
The technical problem of backup for online systems would 
also be formidable. An H/S compatible SAFE would provide some 
"cushion" in a disaster situation where one or the other 
center was damaged or destroyed; or in the unlikely occurrence 
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In an H/S compatible environment, SAFE batch work could 
be supported in the Ruffing Center. The planned SAFE batch 
workload is insignificant and will consist of non-critical 
functions such as the SAFE Management Information System. The 
value of backup for SAFE batch workload is therefore considered 
minor. 

The most practical automated backup for SAFE is the DIA 

(6) 

SAFE system. Both systems will be architecturally identical. 

The practical means by which a CIA analyst could access DIA 

SAFE in the event of a CIA SAFE disaster remains to be studied. 

It is a function of the existence of link between CIA and DIA 

and the survival of a means of access to the link after the 

disaster. At a minimum, CIA analysts could be given physical 

access to DIA terminals during non-prime shift. 

The Ruffing and Special Centers are judged of minor 

value for SAFE disaster backup. Disaster backup for the 

Ruffing and Special Center would primarily be performed in 

non-prime time on the SAFE dual maxi processors (i.e., the 

Document/Catalog Management/Test Search Management/ Index 

Search Management Subsystem). An upper bound, therefore, 

on the value of disaster backup is the systems life cost of 

(7) 

an IBM-compatible dual maxi processor configuration. 

In Appendix D-3(a) an estimate of $4926K is developed for 

the systems life cost of that configuration. It is further 

estimated that 5% of configuration resources would be required 

( 8 ) 

for disaster backup. The value of an IBM-compatible archi- 
tecture for disaster backup is therefore bounded by 5% of 
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$4926K or $246K (1979 dollars) over the systems life. 

(1) Security issues in a disaster backup situation will not be 
addressed in this discussion. 

(2) A formal ODP disaster plan is in preparation in ODP/MS. 

(SAFE will not be included at this time.) 

(3) The ^accessibility of SAFE to general-purpose ODP terminals 
depends on whether ODP has implemented a unified bus architecture 

(4) Because of its limited capacity, the Special Center is 
ignored from this point on as a SAFE backup. 

(5) A method for accessing incoming CIA mail from the Cable 
Dissemination System (CDS) would be required. Distribution of 
hardcopy is a possibility (though a primitive one) . Note that 
use of automated access to CDS or hardcopy distribution is 
independent of SAFE architecture compatibility. 

(6) This is primarily true for SAFE private files. DIA incoming 
mail is not identical to CIA incoming mail. Alternate automated 
approaches probably utilizing Ruffing Center capabilities with 
the Cable Dissemination System (CDS) will be required to access 
CIA mail. A non-automated (and primitive) backup to private 
files such as microform backup could also be made available. 

(7) That is, an equivalent disaster backup to the SAFE dual 
maxi processor configuration could be provided by procuring an 
identical configuration and installing it in a separate "disaster 
facility. Clearly, this is an extravagant solution. Such a 
disaster backup configuration would require an alternate primary 
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use to be cost- justified. The major portion of the cost of the 
disaster facility could therefore be charged to the primary use. 
(8) Five percent configuration resources over the 84-month 
systems life is equivalent to 8.4 months use of 50% of capacity 
(e.g., non-prime shift) for disaster backup. One would hope 
that our current safety posture would limit ODP to, for 
example, one disaster in an 84-month period with 8.4 months 
required to reconstruct and re-equip the destroyed center. 
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